Percolate table is a special table which stores queries instead of documents. It is used for prospective searches (or "search in reverse").
- See section Percolate query for more details about performing a search query against a percolate table.
- See section Adding rules to a percolate table to learn how to prepare a table for searching.
The schema of a percolate table is fixed and contains the following fields:
| Field | Description |
|---|---|
| ID | Unsigned 64-bit integer with autoincrement functionality therefore it can be omitted when you add a PQ rule |
| Query | Full-text query of the rule. You can think of it as the value of a MATCH clause or JSON /search. If per field operators are used inside the query, the full text fields need to be declared in the percolate table configuration. If the stored query is supposed to do only attribute filtering (no full-text querying), the query value can be empty or simply omitted. The value of this field should correspond to the expected document schema which you specify when you create a percolate table |
| Filters | Filters is an optional string containing attribute filters and/or expressions the same way they are defined in the WHERE clause or JSON filtering. The value of this field should correspond to the expected document schema which you specify when you create a percolate table |
| Tags | Optional. Tags represent a list of string labels separated by comma that can be used for filtering/deleting PQ rules. The tags can be returned along with matching documents when you Percolate query |
You don't need to worry about adding the above fields when you create a percolate table.
What you need to take care of when you add a new table is to specify the expected schema of a document which is to be checked against the rules you will add later. This is done the same way as for any other local table.
- SQL
- JSON
- PHP
- Python
- javascript
- java
- CONFIG
$index = [
'index' => 'products',
'body' => [
'columns' => [
'title' => ['type' => 'text'],
'meta' => ['type' => 'json']
],
'settings' => [
'type' => 'pq'
]
]
];
$client->indices()->create($index);utilsApi.sql('CREATE TABLE products(title text, meta json) type=\'pq\'')res = await utilsApi.sql('CREATE TABLE products(title text, meta json) type=\'pq\'');utilsApi.sql("CREATE TABLE products(title text, meta json) type='pq'");Query OK, 0 rows affected (0.00 sec){
"total":0,
"error":"",
"warning":""
}Array(
[total] => 0
[error] =>
[warning] =>
)Template table is a pseudo-table since it does not store any data and does not create any files on your disk. At the same time it can have the same NLP settings as a plain or a real-time table. Template tables can be used for a few purposes:
- as templates to inherit plain/real-time tables in the Plain mode just to minify Manticore configuration file
- keywords generation with help of CALL KEYWORDS
- highlighting of an arbitrary string using CALL SNIPPETS
NLP and tokenization
Manticore doesn't store text as is for performing full-text searching on it. Instead it extracts words and creates several structures that allow fast full-text searching. From the found words, a dictionary is built, which allows a quick look to discover if the word is present or not in the index. In addition, other structures record the documents and fields in which the word was found (as well as position of it inside a field). All these are used when a full-text match is performed.
The process of demarcating and classifying words is called tokenization. The tokenization is applied at both indexing and searching and it operates at character and word level.
On the character level, the engine allows only certain characters to pass, this is defined by the charset_table, anything else is replaced with a whitespace (which is considered the default word separator). The charset_table also allows mappings, for example lowercasing or simply replacing one character with another. Besides that, characters can be ignored, blended, defined as a phrase boundary.
At the word level, the base setting is the min_word_len which defines the minimum word length in characters to be accepted in the index. A common request is to match singular with plural forms of words. For this, morphology processors can be used.
Going further, we might want a word to be matched as another one - because they are synonyms. For this, the word forms feature can be used, which allows one or more words to be mapped to another one.
Very common words can have some unwanted effects on searching, mostly because of their frequency they require lots of computing to process their doc/hit lists. They can be blacklisted with the stop words functionality. This helps not only on speeding queries, but also on decreasing index size.
A more advanced blacklisting is bigrams, which allows creating a special token between a 'bigram' (common) word and an uncommon word. This can speed up several times when common words are used in phrase searches.
In case of indexing HTML content, it's important to not index the HTML tags, as they can introduce a lot of 'noise' in the index. HTML stripping can be used and can be configured to strip, but index certain tag attributes or completely ignore content of certain HTML elements.